Added home, data, config paths #1373
Conversation
|
Thinking about migration. Should we have a script that checks for the old registry file on startup and moves it to the new place in 5.0? |
|
For the non-deb/rpm case, the old location is anyone's guess. It was |
|
This is now ready for reviews. The rest of the items #1371 will be done in other PRs. |
| @@ -14,7 +14,7 @@ import ( | |||
|
|
|||
| // Defaults for config variables which are not set | |||
| const ( | |||
| DefaultRegistryFile = ".filebeat" | |||
| DefaultRegistryFile = "registry" | |||
There was a problem hiding this comment.
I think we should add the .json extension to the name.
There was a problem hiding this comment.
The reason I used registry is that on DEB/RPM installations the file name already used is /usr/share/filebeat/registry. By using registry we can keep BC for those cases at least.
In addition, JSON is an implementation detail which we might change in the future. Also, adding the extension could be inviting people to edit the file, which I guess is the last thing we want.
I see the three +1, but is there a strong reason to add the .json?
There was a problem hiding this comment.
Removed my +1 as I think the point about implementation and potentially changing in the future is a good point. So even if we switch to the format "xyz" the file name stays the same.
There was a problem hiding this comment.
I don't have a strong opinion here. So leaving it as registry is fine with me. (I never meant to +1 my own comment anyways; I didn't realize clicking the thumb icon added a +1 until after I clicked it, and then I couldn't figure out how to undo.)
The reason I used registry is that on DEB/RPM installations the file name already used is /usr/share/filebeat/registry. By using registry we can keep BC for those cases at least.
Those installations were using a non-default value so they should not be affected by the change.
In addition, JSON is an implementation detail which we might change in the future.
True, leaving it without an extension makes it easier to change underlying file type.
There was a problem hiding this comment.
Those installations were using a non-default value so they should not be affected by the change.
Good point. But if it's just registry I can get rid of one of those nasty sed commands on the configuration file at package time by just setting the data path in the init script.
|
It would be good to do a search for |
|
I replaced all occurrences of |
| @@ -390,13 +390,13 @@ filebeat: | |||
|
|
|||
| ===== registry_file | |||
|
|
|||
| The name of the registry file. By default, the registry file is put in the current | |||
| working directory. If the working directory changes for subsequent runs of Filebeat, indexing starts from the beginning again. | |||
| The name of the registry file. If a relative path is used, it is considered relative to the | |||
There was a problem hiding this comment.
I'm not sure what you mean by data path here. Do you mean relative to the folders that are being crawled? Does that mean there is more than one registry file?
* Adds the CLI flags for 'path.home', 'path.data', 'path.config'
* These can be also set in the configuration file:
```
path:
home: /tmp/
data: /tmp/data/
config: /tmp/config/
```
* Filebeat registry location is now by default `{data_path}/registry`. Note: this is
a breaking change from `.filebeat` previously in 1.X.
* The ES templates are searched by default in the config path
|
Cleaned history and rebased to master. |
|
LGTM |
Implements part of #1371.
{data_path}/registry. Note: this isa breaking change from
.filebeatpreviously in 1.X.